It is currently possible for a user to be contacted on several terminals via the same public identity. A public identity of a user, also called IMPU for IP (Internet Protocol) Multimedia Public Identity, corresponds for example to a telephone number assigned by an operator of a communications network, for example an IMS (for IP Multimedia Subsystem) communications network. The public identity assigned to a user allows other terminals to contact the terminal of this user in order to communicate. The user may associate several terminals with the same public identity. Thus, the user can be contacted, via this shared public identity, on any of the terminals which have been associated with this public identity.
Thus, when a caller terminal sends a communication request to the public identity of a user being called, for example by sending a message INVITE according to the SIP protocol (for Session Initiation Protocol), an S-CSCF (for Serving Call Session Control Function) server of the IMS communications network transmits the communication request to all the terminals registered in the IMS communications network with the corresponding public identity. The transmission of the communication request is carried out according to a mechanism called “forking”. The IMS communications network transmits the communication request to all the terminals that have been associated with the public identity and which are connected to the IMS communications network.
The transmission of the communication request to all the terminals may be implemented in parallel or sequentially according to a priority assigned to each terminal associated with the corresponding public identity.
The “forking” mechanism has been described here in the framework of a network “forking” mechanism where the transmission of the communication request to all the terminals associated with the same public identity is implemented by an S-CSCF server of the IMS communications network. The network “forking” mechanism allows a communication request to be transmitted only to destination terminals supporting the SIP protocol.
An applications “forking” mechanism may also be implemented by an applications server of the IMS communications network on a principle similar to that of the network “forking” mechanism. The applications “forking” mechanism allows the communication request to be transmitted to any type of destination terminals supporting the SIP, GSM (Global System for Mobile communications) or RTC (Réseau Téléphonique Commuté) protocol. In the case of the applications “forking”, the destination terminals can then have a different identity. Such destination terminals are then associated by the applications server with a same public identity. Thus, when the caller terminal sends a communication request to such a public identity, all the destination terminals associated to that public identity will receive the communication request.
Upon receiving the communication request, a terminal associated with the corresponding public identity rings in order to inform the user being called of the communication request. The terminal associated with the corresponding public identity also sends a provisional response to the terminal of the caller user, for example in the form of an SIP 180 Ringing message in order to trigger on the terminal of the caller user a ringing return. Each terminal associated with the corresponding public identity and connected to the IMS communications network at the time of the generation of the communication request receives the communication request.
The user being called can then take the communication with any of the terminals having received the communication request.
The mechanism (“forking”) for transmission of the communication request to several terminals associated with the same public identity is transparent for the caller user. The caller user is not therefore aware that his/her communication request is being transmitted to several terminals. The caller user who sends a communication request is not therefore aware, for example, that another user is able to take the communication request if this other user is near to a terminal of the user being called. Or, according to another example, the caller user who sends a communication request does not know that his/her communication request has a high chance of a successful outcome since it is transmitted to several terminals of the user being called.
The RCS (for Rich Communication Suite) communications standard allows a user of an RCS compatible terminal to establish an enhanced communication with another user also in possession of an RCS compatible terminal.
Thus, a voice communication may notably be enhanced by the addition of a video stream to the communication, the sharing of video, audio files, text, etc.
In order for a caller user to be informed of the RCS capacities of the terminal of a user that he/she wishes to call, the terminal of the caller user displays for example to the caller user an enhanced address book comprising the RCS capacities of the terminal of a contact recorded in the address book. The terminal of the caller user regularly updates the RCS capacities of the contacts of the caller user recorded in the address book associated with the terminal of the caller user. For example, the update may be performed at each start-up, or every 24 hours, or at each selection of a contact in the address book. For this purpose, the terminal of the caller user sends to the public identity of each contact recorded in the address book a message to find out the capacities, for example an SIP OPTIONS message according to the SIP protocol. Each terminal of a contact, who has received an SIP OPTIONS message sent by the terminal of the caller user, responds by sending to the terminal of the caller user an SIP 200OK message notably comprising the RCS capacities supported by the terminal of the contact.
The caller user is thus informed of the RCS capacities supported by the terminal of a contact with which he/she wishes to communicate. However, the RCS capacities of the terminal of a contact of the caller user which are stored in the address book of the caller user are not necessarily up to date at the time when the caller user sends a communication request to the terminal of the contact.
Moreover, when a contact of the caller user possesses several terminals associated with the same shared public identity, the SIP OPTIONS message sent by the terminal of the caller user to the shared public identity of the contact is then transmitted by the S-CSCF server of the IMS communications network to all the terminals of the contact associated with said shared public identity according to the “forking” mechanism which is implemented by the IMS communications network. When each terminal of the contact associated with said shared public identity of the contact that has received the SIP OPTIONS message responds by the sending of an SIP 200OK message comprising the RCS capacities supported by the terminal of the contact, the IMS communications network filters the responses sent by the terminals of the contact and only transmits the first SIP 200OK message sent to the terminal of the caller user in response to the SIP OPTIONS message sent by the terminal of the caller user.
The terminal of the caller user is not therefore aware of all of the RCS capacities of the terminals associated with the shared public identity of the contact. The terminal of the caller user is only aware of the RCS capacities supported by the terminal which has responded first to the SIP OPTIONS message. However, the terminal which has responded first to the SIP OPTIONS message is not necessarily that possessing the most appropriate RCS capacities. For example, the terminal which has responded first may indicate that it does not support the addition of video streaming within the voice communication. However, the user being called may have another terminal supporting the addition of video streaming within the voice communication. If the caller user wished to use this functionality during a communication with the user being called, he/she may then decide not to establish a communication with the user being called. The terminal of the caller user thus displays to the caller user RCS capacities relating to the user being called that are incomplete.
Thus, when the caller user sends a communication request to the public identity of a contact, the RCS capacities associated with the contact which are stored in the address book of the caller user are not necessarily up to date.
Moreover, if the contact disposes of several terminals associated with the same public identity, the RCS capacities associated with the contact that are stored in the address book of the caller user are not representative of the RCS capacities supported by all the terminals to which the communication request is transmitted by the communications network and which are able to respond to the communication request.
Moreover, if the contact disposes of several terminals associated with the same public identity, the caller user is not aware that his/her communication request is transmitted to several terminals.